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The  Need 


Because  construction  costs  are  continuously  rising,  Congress 
mandated  that  those  within  the  respective  branches  of 
military  service  who  are  responsible  for  planning  and 
executing  construction  programs  develop  policies  and 
procedures  that  ensure  that  the  individual  projects  a:  e 
designed,  bid,  and  constructed  as  rapidly  as  possible.  This 
requires  an  approach  that  demands  maximum  efficiency  from 
the  design  process.  Reviews  are  necessary  to  ensure  that 
designs  meet  all  requirements,  but  the  reviews  themselves 
must  be  conducted  in  the  least  amount  of  time  so  as  to 
preclude  delays.  Such  tardiness  could  result  in  important 
recommendations  being  given  less  than  appropriate  attention 
by  the  responsible  designer  and  subsequent,  costly  post¬ 
award  contract  modifications. 

A  thorough  review  of  construction  design  documents  is  a 
critical  element  of  the  procurement  of  professional  design 
services.  The  owner,  for  whom  the  services  are  performed, 
wants  to  ensure  that  design  provides  the  functional  utility 
that  he  envisioned.  At  the  same  time,  the  designer  has  an 
interest  in  eliminating  technical  deficiencies,  errors, 
omissions,  and  other  inconsistencies  in  order  to  reduce  his 
potential  liability.  The  construction  contractor  is 
interested  in  discovering  any  interface  problems  and 
resolving  any  conflicts  there  may  be  between  the 
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construction  documents  and  the  existing  site  conditions. 

Flawed  design  documents  ", . .can  be  the  result  of  too  short  a 
time  for  preparation  and  review,  laziness  in  not  searching 
out  the  proper  language,  inadequate  recognition  of  the 
proper  assignment  of  risks,  or  just  ignorance  as  to  what  is 
right  and  what  is  wrong  for  the  particular  project.  They  can 
also  be  the  result  of  a  client,  particularly  a  public 
agency,  providing  rigid  general  conditions  and  format 
requirements. . (Riggs,  1979) .  Fortunately,  since  this 
observation  was  made,  many  changes  have  been  implemented  in 
the  Federal  Governments’  procurement  policy,  which  have 
culminated  in  the  implementation  of  the  Federal  Acquisition 
Regulations  (FAR) .  This  document  has  codified  and 
standardized  the  procurement  policies  and  practices  for  all 
Federal  agencies  into  a  more  enlightened  approach  similar  to 
that  being  practiced  in  the  private  sector. 

However,  the  FAR  is  not  a  panacea  for  problems  with  design 
deficiencies.  These  can  derive  from  the  methods  specified 
within  the  FAR  to  procure  the  design  services,  which  hastens 
the  need  for  a  thorough  design  review.  In  most  cases 
involving  military  construction  projects,  professional 
construction  management  services  are  separate  from  the 
contract  for  design  services.  The  designers  obligation  is 
complete  and  his  services  are  terminated  when  he  delivers  a 
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final  design  that  is  deemed  ready  to  advertise.  From  that 
point  on,  the  process  shifts  focus  to  the  award  of  the 
contract  and  the  physical  act  of  construction.  The  designer 
has  little  formal  opportunity  to  interface  with  the 
contractor,  except  in  conjunction  with  conflict  resolution 
procedures.  This  fosters  defensive  attitudes  among  the 
parties  and  reinforces  the  need  for  error-free  designs. 

A  study  of  the  causes  and  costs  of  modifications  to  military 
construction  contracts,  by  Mogren  found  that  the  major 
causes  of  modifications  were  design  deficiencies,  customer 
requested  changes,  and  unknown  site  conditions.  Of  the 
design  deficiencies,  most  were  found  to  relate  to 
Architectural  aspects  of  the  design,  followed  in  frequency 
by  errors  in  the  Mechanical,  then  Electrical  disciplines. 
The  study  found  design  deficiencies  to  account  for  33.2%  of 
the  total  number  of  change  orders,  and  36.3%  of  the  total 
cost  of  all  modifications.  In  both  categories,  design 
deficiencies  were  the  greatest  single  statistic,  (Mogren, 
1986)  . 

Regardless  of  the  causes  for  design  defects,  the  blame  for 
them  cannot  be  targeted  solely  at  the  designer.  The  level  of 
influence  over  costs  is  greatest  during  the  design  phase,  so 
it  is  then  that  knowledge  brought  to  the  design  by  the 
construction  management  expert  will  be  most  beneficial 
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(Stukhart ,  1987) . 


In  the  public  sector,  construction  management  services  are 
performed  by  the  respective  uniformed  service  component 
Engineer  Corps,  i.e.,  NAVFAC  for  the  Navy,  Corps  of 
Engineers  for  the  Army,  etc.  In  the  private  sector,  this 
function  is  performed  under  a  Construction  Management 
contract.  In  both  sectors,  the  owner  is  given  ample 
participation  in  the  design  process  through  the  review  of 
the  design  documents,  usually  at  the  35%  and  100%  stages. 


Construction  managers  contribute  to  the  control  of  time, 
cost  safety,  and  quality  in  the  construction  of  a  facility. 
In  the  oninion  of  the  Construction  Management  Committee  of 
the  Construction  Division  of  ASCE  (Stukhart,  1987), 
construction  managers  "possess  experience  and  a  high  degree 
of  competence  in  the  following: 

1.  Planning,  organizing,  directing,  and  controlling 
construct  ion . 

2.  The  latest  construction  technology. 

3.  Materials  management,  including  availability  and 

cost  . 


4.  Quality  management. 

5.  labor  availability,  use  and  productivity. 

6.  Cost  engineering,  including  estimating  and 
schedul ing . 
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7.  Contracting  strategy. 

8.  Value  engineering. 

9.  Risk  management." 

Given  these  skills,  the  construction  manager  can  contribute 
to  the  constructability  of  the  design  by  making 
recommendations  regarding  "contract  packaging,  construction 
sequencing,  construction  cost,  access  to  work,  safety,  work 
rule  and  jurisdictional  effects,  construction  methods, 
materials  and  minimization  of  construction  interferences,  as 
well  as  design  detail  improvements". 


THE  REVIEW  PROCESS 

The  review  of  construction  project  plans  and  specifications 
ensures  that  they  are  technically  adequate,  functionally 
adequate,  i.e.,  the  project  will  result  in  a  complete  and 
usable  facility  that  matches  the  users  expectations  and 
operational  needs  ,  and  that  the  design  is  c on st rue t ab 1 e . 
This  places  emphasis  on  the  viewing  the  project  in  terms  of 
its  entire  life-cycle  (Kirby,  1988). 

Technical  reviews  focus  on  the  clarity  of  the  documents  from 
the  viewpoint  of  the  contractor.  Points  considered  in  a 
technical  review  include  visual  accuracy  and  clarity;  i.  e., 
are  the  details  sufficient  and  clear  enough  so  that  a 
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prospective  contractor  will  know  without  doubt  the  precise 
intent  being  conveyed?  Are  the  design  documents  overly 
complicated?  Are  there  ambiguities  between  separate 
drawings?  Between  the  plans  and  specifications?  Are  the 
specifications  complete  and  concise?  Will  the  design  result 
in  reasonable  and  responsive  bids? 

Constructability  implicitly  relates  the  design  to  the 
materials  and  methods  that  will  be  needed  to  construct  it . 
Such  issues  as  ease  of  construction,  efficiencies  of  labor 
productivity  and  equipment  utilization,  site  conditions  and 
layout,  and  others,  are  the  focus  of  a  constructability 
review.  Are  there  methods  and  materials  that  would  make  the 
design  easier  to  build  without  sacrificing  the  basic 
concept? 

Operability  refers  to  the  considerations  made  during  the 
design  cycle  that  relate  to  the  ease  with  which  the  facility 
can  be  operated  and  maintained.  Anticipated  facility  life 
must  be  taken  into  consideration  in  the  cost  of  and  types  of 
materials  selected,  as  must  anticipated  future  facility 
requirements.  In  addition,  the  design  must  be  in  compliance 
with  current  master  plans  and  relate  well  architecturally  to 
other  facilities  planned  or  existing  nearby. 

Basic  NAVFAC  policy  governing  the  preparation  and  review  of 
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design  documents  requires  that  technical,  functional  and 
constructabi 1 ity  reviews  be  conducted  at  the  35%  and  100% 
phases  of  design  preparation.  Prior  to  any  external 
scrutiny,  however,  the  persons  preparing  the  specification 
are  required  to  review  the  drawings  to  ensure  that  materials 
and  systems  appearing  on  them  are  covered  and  that  all 
requirements  necessary  t  <->  accomplish  the  work  are  adequately 
expressed.  Those  preparing  drawings  are  similarly  required 
to  review  the  spec i f icat i ons  so  as  to  ensure  complete 
coordination  (MIL-HDBK  1006/1,  1987). 

Once  the  drawings  and  specifications  have  been  coordinated, 
these  technical,  functional  and  constructabi 1 ity  reviews  are 
typically  performed  separately  by  groups  of  individuals  in 
whom  lies  the  special  expertise  required  for  each  of  the 
types  of  review.  This  includes  the  end-user,  who  may  or  may 
not  have  any  expertise  to  properly  review  construction 
drawings  and  specifications.  The  reviews  result  in  many 
comments  from  many  people,  each  of  whom  has  his  own 
background,  experience  and  bias.  Coordination  of  all  of 
these  comments  is  the  responsibility  of  the  design  project 
manager  at  the  Engineering  Field  Division  (EFD) .  He  is  the 
primary  interface  between  the  governmental  agency  proposing 
the  project  and  the  design  Archit ect/Engineer  firm 
contracted  to  perform  the  service.  Typically,  the  EFD  and 
the  Installation  requesting  the  work  are  geographically 
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separate  which  adds  time  for  mailing  and  returning  the 
plans,  specif ications ,  and  comments.  Depending  on  the  size 
and  complexity  of  the  project,  there  could  be  hundreds  of 
comments  submitted  by  several  reviewers  at  each  stage  of 
review.  The  design  project  manager  is  quite  likely  to  be 
assigned  several  design  projects  to  coordinate  at  any  time. 

All  of  this  points  to  the  difficulties  that  are  routinely 
encountered  and  adds  credence  to  the  need  for  a  viable 


review  system 

that  is 

time  sensitive 

and 

considerate  of  the 

separate  and 

diverse 

backgrounds 

of 

the  many  people 

conducting  the 

review. 

n 
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CHAPTER  TWO 


ABOUT  EXPERT  SYSTEMS 


"  An  expert  is  a  person  who,  because  of 
training  and  experience,  is  able  to  do  things 
the  rest  of  us  cannot;  experts  are  not  only 
proficient  but  also  smooth  nd  efficient  in 
the  actions  they  take.  Experts  know  a  great 
many  things  and  have  tricks  and  caveats  for 
applying  what  they  know  to  problems  and 
tasks;  they  are  also  good  at  plowing  through 
irrelevant  information  in  order  to  get  at 
basic  issues,  and  they  are  good  at 
recognizing  problems  they  face  as  instances 
of  types  with  which  they  are  familiar. 
Underlying  the  behavior  of  experts  is  the 
body  of  operative  knowledge  we  have  termed 
expertise.  It  is  reasonable  to  suppose, 
therefore,  that  experts  are  the  ones  to  ask 
when  we  wish  to  represent  the  expertise  that 
makes  their  behavior  possible".  (Johnson, 
1983) 
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knowledge-based  expert  systems^  (KBES)  are  interactive  computer 
programs  that  incorporate  judgement,  experience,  rules  of  thumb, 
and  other  expertise,  so  as  to  provide  knowledgeable  advice  about 
a  specific  domain.  They  mimic  the  thought  process  employed  by  a 

A 

human  expert  in  solving  a  problem.  They  are  fundamentally 
different  from  the  traditional,  algorithmic  types  of  computer 
applications  that  everyone  is  familiar  with  in  several  areas. 
Algorithmic  programs  process  numbers.  They  are  usually  designed 
to  solve  a  very  narrow  range  of  a  specific  family  of  problems. 
For  example,  algorithms  are  adept  at  determining  the  critical 
path  in  a  complex  construction  schedule,  or  designing  structural 
beams  for  certain  specified  combinations  of  loads.  These  programs 
can  be  quite  sophisticated,  but  are  sequential  in  nature  and  deal 
only  with  the  information  included  in  the  procedural  code  of  the 
program  itself  and  any  variable  data  that  is  input.  Once  the 
program  begins  its  execution,  it  continues  to  completion,  or 
until  it  is  instructed  to  stop  to  pick  up  more  data.  It 
incorporates  high-level  knowledge,  assumptions  and  rules  of 
thumb,  but  these  are  built  in  to  the  programs  code. 

An  algorithm  cannot  draw  conclusions  or  make  inferences.  In 
essence  these  programs  replicate  the  actions  of  a  designer 
punching  the  numbers  into  his  calculator.  The  program  yields  beam 
sizes  or  shear  and  bending  moment  data,  just  as  the  engineer 
would  have  arrived  at  himself.  The  major  accomplishment  of  this 
type  of  program  is  that  it  frees  the  designer  from  the  laborious 
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effort  of  performing  the  calculations  himself.  The  family  of 
algorithmic  programs  is  to  the  calculator  what  the  microwave  oven 
is  to  the  traditional  kitchen  device,  namely  a  labor  saver. 

Knowledge-based  expert  systems  are  a  major  step  forward  in  the 
development  of  the  computer  as  a  useful  tool.  KBES  origins  are 
fairly  recent,  coming  out  of  research  first  conducted  in  the 
1960’s  as  an  adjunct  to  the  study  of  computer  science  called 
artificial  intelligence  (AI) .  Unlike  their  algorithmic  number¬ 
crunching  cousins,  the  early  AI  programs  attempted  to  process 
symbols . 

Early  applications  were  cumbersome  and  extremely  limited,  just  as 
the  early  algorithmic  applications  were.  Beyond  being  able  to 
solve  certain  puzzles,  and  perform  other  limited  tasks,  the  more 
complicated  the  problem  that  was  attempted,  the  longer  the 
program  took  to  solve  it.  These  diminishing  returns  relegated  the 
study  of  the  usefulness  of  AI  to  institutions  of  higher  education 
as  not  much  more  than  an  academic  novelty  . 

Although  the  AI  programs  processed  symbols,  just  as  humans  do, 
they  were  constructed  using  the  experience  gained  in  algorithmic 
processing.  This  meant  that  the  information  being  processed  was 
imbedded  in  the  procedural  code  and  manipulated  in  the  same 
sequential,  iterative  process  that  is  common  to  algorithms. 
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Practitioners  soon  realized  that  drastic  improvements  to  the 
capability  of  the  system  could  be  achieved  if  the  procedural,  or 
control  apparatus  was  separate  from  the  knowledge  being  acted 
upon.  This  more  closely  resembles  the  way  human  inference  works 
and  is  the  most  fundamental  difference  between  KBES  programs  and 
traditional  algorithms. 

A  KBES  manipulates  knowledge  it  possesses  based  upon  recognitions 
that  it  is  able  to  make  because  of  the  control  strategy  that  is 
built  into  the  system.  "The  central  notion  of  intelligent 
problem-solving  is  that  a  system  must  construct  its  solution 
selectively  and  efficiently  from  a  space  of  alternatives.  When 
resource-limited,  the  expert  needs  to  search  this  space 
selectively,  with  as  little  unfruitful  activity  as  possible.  An 
expert's  knowledge  helps  spot  useful  data  early,  suggests 
promising  ways  to  exploit  them,  and  helps  avoid  low-payoff 
efforts  by  pruning  blind  alleys  as  early  as  possible.  An  expert 
system  achieves  high  performance  by  using  knowledge  to  make  the 
best  use  of  its  time"  (Hayes-Roth,  1983) . 

COMPONENTS  OF  A  KBES 

A  discussion  of  the  basic  components  of  a  KBES  can  be  found  in 
any  of  several  books  on  the  subject.  The  following  discussion  is 
taken  from  Waterman's  A  Guide  to  Expert  Systems  (Waterman,  1986), 
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and  class  notes  from  the  course  of  instruction  at  the  Georgia 
Institute  of  Technology  CE  8113  "KBS  for  Civil  Engineers". 

THE  KNOWLEDGE  BASE: 

The  knowledge  base  in  a  KBES  is  organized  using  rules  and  facts. 
The  rules  may  take  the  form  of  heuristics,  or  rules  of  thumb. 
These  effectively  define  the  limits  within  the  domain  to  search. 
They  are  typically  symbolic  and  not  amenable  to  rigorous 
mathematical  operation.  Whereas  an  algorithm  can  act  upon  a  small 
amount  of  knowledge  with  great  speed  and  precision,  guaranteeing 
an  exact  solution,  the  heuristic  approach  is  to  search 
selectively  through  a  large  knowledge  base  arriving  at 
conclusions  by  comparing  facts  it  has  been  given  with  knowledge 
that  it  already  possesses,  forming  new  knowledge  in  the  process. 

Knowledge  is  usually  represented  as  rules  or  frames.  Rule-based 
knowledge  representation  takes  the  form  of  the  conditional  I  F  - 
THEN-ELSE  statement.  As  an  example: 

IF  This  is  a  35%  design  review 

THEN  There  should  be  a  draft  specification 

IF  There  is  a  draft  specification 

THEN  Check  for  wording  "as  directed" 

AND  "where  directed" 
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IF 


There  is  wording  "as  directed' 


OR  "where  directed" 

THEN  Verify  items  are  so  indicated  on  drawings 

IF  Facility  is  a  truck  fueling  facility 

THEN  Verify  rigid  (no  hose)  loading  arms  are  indicated 

on  drawings  and  in  specifications 

The  current  state  is  given  in  statements  of  fact.  These  are  given 
separately,  and  represent  the  problem  statement. 

FACT  This  is  a  35%  review 

FACT  The  facility  is  a  truck  fuelling  facility 

FACT  The  project  is  located  at  NAS  Atlanta 

Facts  are  compared  to  the  rules  and  matches  are  made,  or  not 
made.  A  match  represents  a  new  fact  and  it  is  compared  to  the  set 
of  alternatives  until  another  match  is  made,  and  so  on,  until 
there  are  no  more  matches,  or  until  the  system  is  told  to  stop. 
The  end-product  is  a  conclusion  that  is  based  on  inference  chains 
made  by  comparing  facts  to  rules. 

Frame-based  knowledge  systems  are  specialized  semantic  networks. 
Each  frame  consists  of  information  that  is  arrayed  in  a  network 
of  nodes  and  relations.  The  information  within  the  nodes  is 
arranged  according  to  a  hierarchy  whereby  the  upper  nodes  are 
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more  general,  and  the  lower  nodes  are  more  detailed.  Each  node  is 
defined  by  a  collection  of  attributes  such  as  name,  size, 
configuration,  etc.,  and  values  such  as  truck  fueling  facility, 
medium,  multi-lane,  etc.  Each  node  inherits  the  properties  of  the 
those  higher  than  it.  The  arcs  connecting  the  nodes  are  called 
"isa".  Because  the  properties  of  the  individual  nodes  are  known 
and  the  relations  linking  them,  the  "isa"  are  transitive,  for  any 
two  nodes  given,  a  third  can  be  inferred.  To  illustrate,  take  the 
following  example:  "A  Volvo  is  an  automobile"  and  "  all 
automobiles  are  motor  vehicles".  Thus,  one  can  infer  that  a  Volvo 
is  a  motor  vehicle,  even  though  it  is  not  explicitly  stated.  The 
property  inheritance  hierarchy  in  the  network  is  established  by 
the  "isa"  arc  . 


THE  INFERENCE  ENGINE 

The  inference  engine  provides  the  means  of  using  the  domain 
knowledge  to  solve  problems.  That  part  of  the  inference  engine 
that  decides  how  to  apply  domain  knowledge  is  the  interpreter. 
That  part  of  the  inference  engine  that  decides  when  and  in  what 
order  to  apply  different  pieces  of  domain  knowledge  is  the 
scheduler.  Together,  these  comprise  the  inference  method  used  by 
the  inference  engine. 


Some  KBES  use  a  "forward  chaining"  inference  method.  The 
production  rules  for  such  a  method  are  written  with  a  left  hand 
side  and  a  right  hand  side.  These  sides  correspond  to  the 
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conditional  IF  ===>  THEN  statement.  The  chaining  proceeds  in  the 
direction  of  the  arrow.  For  example: 

FACTS  RULES 


A 

IF 

F 

&  B  THEN 

Z 

B 

IF 

C 

&  D  THEN 

F 

C 

IF 

A 

THEN  D 

The  first 

two 

rule  each 

require  fact 

s 

that  are 

not  initially 

present  so 

they 

cannot  f 

ire.  However, 

because  A  is 

present ,  then 

D  can  be  inferred,  and  added  to  the  knowledge  base.  The  rule 
A  ===>  D  is  removed  since  it  has  been  satisfied.  The  next 
production  rule  to  fire  is  C  &  D  ===>  F,  since  there  is  still  not 
enough  knowledge  to  satisfy  the  first  rule.  Now  that  the  second 
rule  has  fired,  F  is  inferred  and  added  to  the  knowledge  base, 
enabling  the  first  rule  to  fire. 
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I 

I 


Z  In  this  example,  control  begins  at  the 

/  \  bottom,  and  progresses  forward  to  reach 


F 

B 

a  conclusion  at  Z. 

The  network  assumes 

/ 

\ 

that  all  the  related 

information  below 

c 

D 

any  particular  node 

must  be  known  before 

\ 

A 

any  forward  movement 

can  occur . 

i  in 

s  equenc  e 

,  the 

inference  process  look 

s  1 ike  this: 

RUM 

INITIAL 

FACTS 

RULES 

FINAL  FACTS 

A 

F  &  B  ===>  Z 

A  D 

1 

B 

C  &  D  ===>  F 

B 

C 

A  ===>  D  * 

C 

A 

D 

F  &  B  ===>  Z 

A  D 

2 

B 

C  &  D  ===>  F  * 

B  F 

C 

C 

A 

D 

F  &  B  ===>  Z  * 

A  D 

3  B  F  B  F 

C  C  Z 


Forward  chaining  is  data-dir ect ed  and  is  not  usually  appropriate 
unless,  as  in  the  case  above,  there  is  only  one  situation  (Z) 
that  can  be  proven,  given  A,B,  and  C.  A  real-world  network  would 
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have  hundreds  or  thousands  of  inference  chains  possible,  some  of 
which  might  be  valid,  but  would  not  necessarily  lead  to  the 
inference  of  the  existence  of  Z.  This  strategy  is  inefficient  in 
those  cases  . 


On  the  other  hand,  a  "backward  chaining"  inference  method  is 
goal-directed.  Using  the  same  information  as  in  the  example 
above,  the  object  will  be  not  to  see  what  can  be  inferred  from  A, 
B,  and  C,  but  whether  or  not  Z  can  be  proven,  given  them.  The 
system  first  checks  to  see  if  Z  is  already  present  in  the  set  of 
known  facts.  Finding  it  absent,  the  system  looks  at  the  rules  to 
see  which  of  them  produces  the  result,  Z.  Applying  F  &  B  ===>  Z, 
to  the  facts,  B  is  found,  but  F  is  absent.  Now  the  system  looks 
for  the  rule  that  infers  F,  and  finds  C  &  D  ===>  F.  A  search  of 
the  facts  finds  C,  but  not  D.  Finally,  the  system  finds  the  rule 
A  ==>  D.  Since  it  has  found  all  matches  that  were  previously 
absent,  the  system  reverses  itself  by  adding  D  to  the  knowledge 
base  and  executing  the  rules  until  it  infers  that  Z  exists. 


Z 

/  \ 

F  B 

/  \ 

C  D 

\ 

A 


The  control  begins  at  Z  at  the  top 
of  the  network  and  progresses 
backward,  trying  to  establish  the 
existence  of  Z  by  proving  the 
antecedents  of  Z.  This  network  also 
assumes  that  all  the  information 
below  any  node  must  be  known. 
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The  backward  chaining  control  strategy  took  the  following  steps 
to  infer  the  existence  of  Z: 


1.  Z  not  present  in  facts. 

F  and  B  needed  to  prove  Z. 

2.  B  present  in  facts,  but  not  F. 

C  and  D  needed  to  prove  F. 

3.  C  present  in  facts,  but  not  D. 

A  needed  to  prove  D. 

4.  A  present  in  facts. 

Infer  the  existence  of  D.  Add  to  knowledge  base. 

5.  C  and  D  present  in  facts. 

Infer  the  existence  of  F.  Add  to  knowledge  base 

6.  F  and  B  present  in  facts. 

Infer  the  existence  of  Z. 


Control  strategies  can  be  further  separated  into  "dept h- f i r s t "  or 
"breadth-first"  chaining.  Using  the  network  below  to  illustrate, 
and  assuming  forward  chaining,  a  breadth-first  search  would 
require  that  ail  of  A.,  B,  C,  D  and  E  be  present  in  the  facts 
before  F,  G,  or  H  be  considered.  A  depth-first  search  would 
require  that  A  and  B,  only,  be  present  in  order  to  consider  F.  F 
and  G  must  be  present  in  order  to  consider  I,  and  so  on. 
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I 

I 


H 

\ 

E 

The  backward  chaining,  depth-first  operation  would  start  at  K, 
then  move  to  either  I  or  J  (in  no  particular  sequence) .If  I  is 
true  then  F  is  tested,  and  sc  on.  If  F  is  false  then  G  is  tested. 
If  both  F  and  G  are  false,  then  J  is  tested.  The  breadth  first 
procedure  requires  that  both  I  and  J  must  be  considered  before 
any  movement  to  lower  levels  is  considered.  If  I  is  not  true, 
then  H  is  considered,  etc. 

Different  control  strategies  have  different  applications  in  the 
commercial  market.  Most  shells  written  for  PC  use  are  depth  first 
and  can  be  either  forward  or  backward  chaining,  but  not  usually 
both.  Systems  written  for  mini-computer  or  main  frame  use  can  be 
more  flexible.  YAPS,  for  instance,  is  forward  chaining,  but  can 
be  made  to  simulate  backward  chaining.  Different  programming 
languages,  called  expert  system  tools  have  been  developed  for 
different  kinds  of  applications.  EMYCIN  was  derived  from  MYCIN, 
an  expert  system  developed  to  help  diagnose  and  treat  bacterial 


K 


I 


/  \ 

I  J 

/  \  \ 
F  G 

/  \  \  / 

A  BCD 
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infections.  It  uses  IF-THEN  rules  to  perform  forward  or  backward 
chaining  for  rule-based  knowledge  applications.  SRL  uses  frame 
hierarchies  for  inheritance  and  procedural  attachment  for  frame- 
based  knowledge  applications.  Common  LISP  (formerly  Franz  LISP) 
uses  nested  subroutines  to  organize  and  control  program  execution 
for  procedure-oriented  applications.  There  are  also  languages  for 
object-oriented,  1 ogic- or i ent ed ,  and  access-oriented 
applications.  A  complete  catalog  of  expert  system  tools  can  be 
found  in  (Waterman,  1986) . 

THE  EXPLANATION  FACILITY 

The  explanation  facility  is  that  part  of  the  expert  system  that 
explains  how  solutions  were  reached  and  justifies  the  steps  used 
to  reach  them. 

THE  KNOWLEDGE  ACQUISITION  FACILITY 

Perhaps  the  most  critical  component  to  the  system  is  not  the 
knowledge-base  itself,  but  how  it  is  acquired.  This  is  the 
function  of  the  knowledge  acquisition  facility.  The  successful 
KBES  must  have  both  the  appropriate  knowledge  and  the  means  to 
use  it  effectively  or  there  would  be  no  need  for  it. 


DOMAIN  KNOWLEDGE 


There  is  an  immense  amount  of  knowledge  about  technical  and 
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functional  aspects  of  a  construction  project,  as  well  as  about 
constructability  issues.  This  knowledge  is  of  two  basic  types; 
general  or  systemic  knowledge-that  which  applies,  more  or  less 
to  all  construction  projects,  and  specific  knowledge-that  which 
is  applicable  to  certain  specific  categories  of  c onstruct i on .  Put 
into  context,  a  reviewer  would  generally  check  every  design  to 
ensure  that  items  specified  "as  indicated"  and  "where  indicated" 
were  in  fact  shown  to  be  so  on  the  drawings.  On  the  other  hand, 
only  an  expert  reviewer  would  have  the  specific  knowledge  to 
verify  that  rigid  pipe  (no  hose)  loading  arms  should  be  provided 
at  POL  facility  truck  stands,  and  that  hoses  were  appropriate  for 
rail  off-loading  only. 

By  using  the  Department  of  the  Manual  of  Navy  Facility  Category 
Codes,  P-72,  knowledge  bases  can  be  developed  that  will  include 
both  general  and  specific  knowledge  for  each  specific  type  of 
facility  listed.  Specific  knowledge  about  waterfront  facilities 
may  have  little  applicability  to  air  control  administrative 
buildings . 

The  notion  of  specialization  is  best  demonstrated  by  the  field  of 
medicine  where  there  are  many  separate  groups  of  practitioners 
who  know  a  great  deal  about  a  very  narrow,  yet  complex  field,  but 
all  have  essentially  the  same  prerequisite  knowledge.  Because 
there  is  an  abundance  of  knowledge  within  the  domain  of  medicine, 
and  the  knowledge  can  be  organized  by  specialty,  and  meets  a 
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number  of  other  considerations  that  are  discussed  in  the  next 


chapter,  there  are  more  successfully  functioning  KBES  than  in  any 
other  professional  endeavor. 

FEASIBILITY  DETERMINATION 

A  KBES  may  not  be  able  to  outperform  an  expert.  It  could  be 
too  slow,  too  expensive  to  develop  or  operate,  too  limited 
in  its  ability,  or  it  may  possess  any  number  of  other 
def ic i enc i es .  Therefor,  it  is  well  worth  the  effort  to 
subject  any  task  that  is  envisioned  as  a  candidate  for  KBES 
development  to  a  rigorous  analysis  that  will  demonstrate 
that  the  candidate  task  is  suitable,  justified,  and 
appropriate  . 

SUITABILITY: 

Waterman  (Waterman,  1986)  considers  a  task  to  be  suitable 
for  KBES  development  if  the  following  conditions  are  met: 

1.  The  task  does  not  require  common  sense.  Such  a  task 

would  clearly  be  beneath  the  effort  of  a  KBES. 

AND 

2,  The  task  requires  only  cognitive  skills.  There  is  no 
requirement  to  physically  manipulate  anything,  such  as 

a  bank  of  switches,  or  valves,  etc. 

AND 
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3.  Experts  can  articulate  their  methods.  The  methods 
are  not  so  complicated  or  so  heuristic  that  they  cannot  be 

replicated. 

AND 

4.  Genuine  experts  exist. 

AND 

5.  Experts  all  agree  on  solutions. 

AND 

6.  The  task  is  not  too  difficult. 

AND 

7.  The  task  is  not  poorly  understood. 

If  all  of  these  conditions  can  be  satisfied,  then  the  task 
is  at  least  suitable  for  consideration  for  development.  In 
this  case,  the  task  is  performing  technical,  functional  and 
constructability  reviews  of  design  drawings  and 
specifications  for  construction  contracts.  The  following 
comments  are  keyed  to  the  points  listed  above  to  demonstrate 
the  suitability  of  the  task. 

1.  Design  documents  are  an  interdisciplinary 

undertaking  between  many  design  professionals.  Each  of  their 
efforts  must  be  coordinated  with  the  other’s.  Not  only  must 
all  of  the  lines  on  all  of  the  drawings  agree  with  each 
other,  but  the  sizes  that  are  shown  and  materials  that  are 
specified  are  the  result  of  high  level  computations  within 
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each  discipline.  In  addition,  design  professionals  are 
highly  specialized  within  their  respective  disciplines,  A 
competent  Structural  Engineer,  for  instance,  may  have  very 
little  knowledge  of  electrical  power  distribution  design 
calculations,  and  would  therefor  not  b?  able  to  detect 
obvious  flaws  in  the  types  or  sizes  of  equipment  being 
specified  and  shown.  It  should  be  clear  then  that  a  person 
tasked  with  reviewing  design  documents  who  has  little  or  no 
experience  ,  i.e.  a  non-expert,  would  not  be  able  to  detect 
errors  and  omissions  that  are  obvious  to  the  practiced 
r evi ewer . 

2.  The  task  requires  only  cognitive  skills.  This  is  not 
as  straight  forward  as  it  sounds.  Often  design  documents 
specify  certain  equipment  in  generic  terms  in  order  not  to 
be  proprietary,  and  depict  these  as  general  shapes  in  the 
spaces  they  are  intended  to  fit,  when  the  actual  equipment 
that  will  be  installed  will  not  be  known  until  after  the 
contract  is  awarded  and  the  winning  contractor  submits  his 
equipment  catalog  cuts  for  approval.  Because  there  is 
usually  a  certain  amount  of  variation  among  manufacturers, 
it  takes  a  skilled  reviewer  to  detect  the  possibility  that 
the  dimensions  on  the  plan  may  not  fit  all  of  the 
possibilities  of  equipment  configuration.  While  there  is  no 
physical  manipulation  per  se,  certain  mental  images  must  be 
constructed  that  approximate  the  same  effect. 
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3.  Most  experts  have  their  own  "system"  for  reviewing 
plans  and  specifications,  but  they  are  almost  all  variations 
on  the  same  theme.  One  of  the  better  known  of  the  published 
methods  was  developed  and  published  by  LCDR  William  Nigro, 
CEC,  USN,  entitled  REDICHECK .  This  particular  method  is 
discussed  in  more  detail  later  in  the  paper.  There  is  other 
published  information  and  a  large  number  of  resident  experts 
to  draw  upon  for  this  information. 

4.  In  addition  to  the  published  literature  on  the 
subject,  genuine  experts  exist  within  the  NAVFAC  family, 
mainly  at  the  Engineering  Field  Divisions,  but  also  at  the 
Headquarters  level,  at  the  Navy  Civil  Engineering 
Laboratory,  and  at  many  of  the  Officer  In  Charge  of 
Construction  and  Resident  Officer  In  Charge  of  Construction 
(OICC/ROICC)  field  offices. 

5.  As  alluded  to  in  the  paragraph  on  experts  being  able 
to  articulate  their  methods,  most  use  similar  methods  to 
begin  with.  Combining  the  best  parts  of  all  of  them  should 
not  be  difficult. 

6.  The  procedure  for  reviewing  plans  and  specifications 
for  constructability  is  methodical  and  systematic  and  should 
be  easy  to  emulate.  The  procedure  is  essentially  the  same 
for  any  review,  with  the  variables  being  in  the  interaction 
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between  the  design  disciplines  themselves. 


7.  The  need  for  and  methodology  of  the  thorough  review 
of  plans  and  specifications  is  well  understood  by  all 
practitioners .  The  difference  between  them  is  their 
individual  capabilities,  which  depends  largely  on  the 
exposure  each  has  had  to  the  process,  or  EXPERTise! 

JUSTIFICATION: 

Once  a  task  has  been  found  to  be  suitable  for  development  as 
a  KBES,  the  next  step  is  to  determine  if  there  is  ample 
justification  to  proceed.  One  or  more  of  the  following 
considerations  must  be  true  in  order  for  the  task  to  be 
justifiable : 

1.  The  task  solution  has  a  high  payoff. 

OR 

2.  Human  expertise  is  being  lost. 

OR 

3.  Human  expertise  is  scarce. 

OR 

4.  Expertise  is  needed  in  many  locations. 

OR 

5.  Expertise  is  needed  in  a  hostile  environment. 

One  can  easily  see  that  conditions  1,  3,  and  4  are  met  for 
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the  task  of  developing  a  KBES  to  perform  constructability 
reviews.  It  should  come  as  no  surprise  to  anyone  involved  in 
the  construction  industry  that  contract  modifications 
arising  from  design  deficiencies  are  expensive.  The  analysis 
by  Mogren  demonstrates  this  point.  Those  people  who  are 
currently  employed  that  could  be  considered  to  be  experts, 
are  located  mainly  at  the  Engineering  Field  Divisions,  and 
at  the  major  OICC  offices.  Having  genuine  experts  available 
at  every  field  office  on  every  occasion  that  a  review  is 
undertaken  would  be  luxuriant,  indeed. 

APPROPRIATENESS : 

The  final  review  of  a  task  to  ensure  that  a  KBES  is 
appropriate  is  to  make  sure  it  has  the  following 
characteristics  : 

1.  The  nature  of  the  task  requires  symbol  manipulation, 
and  heuristic  solutions. 

AND 

2.  The  task  is  sufficiently  complex  to  allow  for  the 
existence  of  genuine  experts. 

AND 

3.  The  scope  of  the  task  indicates  that  it  has 
practical  value,  and  that  it  is  of  manageable  size. 

By  carefully  considering  all  of  the  aspects  of  the  task  of 
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reviewing  construction  project  design  drawings  and 
specifications,  it  can  be  seen  to  be  suitable,  justified, 
and  appropriate  for  development  into  a  KBES . 
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CHAPTER  THREE 


THE  STATE  OF  THE  ART 

CHECKLISTS: 

Most  of  the  domain  knowledge  that  exists  concerning  reviews 
of  this  nature  is  in  the  form  of  checklists.  At  one  end  of 
the  spectrum  are  lists  that  are  general  and  quantitative  in 
nature.  These  focus  on  macro  issues  and  tend  not  to  require 
any  qualitative  judgements.  The  review  of  a  35  %  design 
submittal  should  ensure  that  the  drawings  contain  certain 
minimum  information,  an  outline  project  specification,  a 
preliminary  design  cost  estimate,  initiation  of  certain 
back-up  data  such  as  economic  analysis,  or  environmental 
assessments,  and  so  forth.  The  reviewer  can  make  sure  that 
the  specific  items  are  physically  there  without  having  to 
make  any  serious  value  judgements  about  the  actual  design 
approach.  This  type  of  review  is  appropriate  at  the  design 
project  manager  level  (MIL-HDBK-1006/1 ,  1987). 

At  the  other  end  of  the  spectrum  are  checklists  that  have 
evolved  as  the  result  of  lessons  that  have  been  learned  from 
experience.  These  typically  take  the  form  of  helpful  hints, 
tricks  of  the  trade,  and  rules  of  thumb,  collectively  known 
as  heuristics.  The  source  of  this  body  of  knowledge  comes 
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users 


from  designers,  construction  managers,  constructors, 
and  maintenance  specialists.  One  such  checklist,  REDICHECK 
(Nigro,  1983),  was  developed  so  that  the  ROICC  could 
anticipate  problems  in  time  to  solve  them,  project 
architects  and  designers  could  give  design  submittals  a  more 
thorough,  interdisciplinary  review,  and  A/E  firms  could 
benefit  in  reduced  exposure  to  liability  claims.  It  is  a 
concise  checklist,  divided  into  seven  major  subdivisions, 
which  contain  sixty-two  individual  items  to  check  or  verify. 
It  offers  general  advice  that  can  be  applied  to  the  review 
of  any  facility  design,  such  as  to  verify  that  items 
specified  "as  indicated"  or  "where  indicated"  are  in  fact 
indicated  on  the  contract  drawings  as  well  as  advice  such  as 
to  verify  that  adequate  ceiling  height  exists  at  worst  case 
duct  intersections.  Both  are  examples  of  advice  that  one 
would  expect  an  expert  to  be  able  to  give  to  a  novice. 

The  notion  of  providing  expert  advice  is  taken  a  step 
further  in  the  USAF  Engineering  Technical  Letter  (ETL)  88-4, 
"Reliability  and  Maintainability  (R&M)  Design  Checklist".  In 
it  there  are  seventeen  major  subdivisions  with  a  total  of 
over  600  specific  individual  items  of  advice.  These  appear 
to  be  derived  mainly  from  the  maintenance  specialties  and 
are  no  doubt  the  result  of  frequent  occurrence.  For  example, 
in  Section  Three,  Interior  Electrical,  item  number  24  reads 
"  Are  explosion-proof  f ixt ur es/ sy s t ems  provided  in  areas 
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subject  to  flammable  vapors?  Areas  of  significant  hazard  are 
battery  charging  rooms,  refueler  vehicle  maintenance  bays, 
paint  rooms  and  aircraft  fuel  system  docks"  (USAF  ETL  88-4, 
1988)  . 


AUTOMATED  CHECKLISTS: 


Perhaps  the  most 

ambitious  attempt 

t  o 

dat  e 

to  c omb i n e  the 

best  information 

available  from 

all 

of 

the  sources  of 

knowledge,  is  embodied  in  the 

U.S. 

Army  Construction 

Engineering  Research  Laboratory  development  (Kirby,  1988)  of 
the  Automated  Review  Management  System  (ARMS),  and,  more 
recently,  the  BCO  Advisor.  ARMS  was  developed  beginning  in 
1985  as  a  result  of  the  recognition  that  automated  systems 
were  already  in  place  that  had  the  capability  of  helping  to 
coordinate  the  large  numbers  and  complex  diversity  of 
comments  in  the  relatively  short  times  periods  that  are 
demanded.  It  is  a  UNIX  based  mini-computer  program  written 
in  C  that  is  accessible  directly  or  through  communications 
software/modem  connections  from  any  of  the  geographically 
separate  parties  having  a  hand  in  the  review.  The  program  is 
intended  to  be  utilized  primarily  by  the  design  project 
managers,  review  managers,  reviewers  and  design  A/E  firms  or 
in-house  designers.  It  utilizes  on-screen  versions  of  the 
standardized  hard-copy  forms  that  have  been  used  for  comment 
generation,  and  other  administrative  documents  relative  to 
the  review.  The  system  is  menu  driven  and  user  friendly.  It 
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assists  the  design  project  manager  by  prompting  him  to 
initiate  review  routings  on  pre-planned  dates.  Returned 
comments  are  tracked  in  a  report  that  informs  the  project 
manager  on  a  continual  basis  the  status  of  reviews  including 
any  which  may  be  overdue.  There  are  other  features  of  the 
system  to  help  the  project  manager  plan  future  workloads  as 
well  . 

The  ability  of  the  computer  to  sort  through  fields  of  data 
is  an  advantage  that  is  exploited  by  ARMS.  Comments  can  be 
sorted  by  location,  discipline,  topic,  reviewer,  designer, 
etc.,  into  a  useful  file  of  information.  Once  comments  have 
been  received  and  organized  by  the  project  manager,  they  are 
forwarded  to  the  design  A/E  for  action.  By  stipulation,  each 
comment  must  receive  a  response  from  the  A/E.  If  he  chooses 
to  disagree  with  a  comment ,  or  has  another  reason  not  to 
incorporate  it,  then  the  matter  is  resolved  at  a  meeting 
with  the  project  manager  and  the  reviewer.  The  ARMS  system 
provides  for  a  complete  electronic  record  of  all  design 
review  comments  and  their  exact  disposition.  Eecause  of  the 
sorting  ability  of  the  computer,  these  comments  and  their 
resolution  can  be  retrieved  at  a  subsequent  date  in 
combinations  or  packages  that  can  be  used  as  "lessons 
learned"  in  the  preparation  of  future  designs,  as  well  as 
for  future  reviews.  In  addition,  it  provides  a  concise 
record  that  can  be  helpful  in  the  event  of  future  A/E 
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liability  claims  and  can  also  assist  in  providing  the  basis 
for  evaluation  of  the  A/E  as  well  as  the  reviewers. 

More  importantly,  the  data  base  of  knowledge  grows 
incrementally  with  each  comment/response  pair.  By  using  the 
sort  feature,  a  complete  file  can  be  created  that  includes 
all  attempted  solutions  to  any  problem.  This  will  diminish 
those  difficulties  that  seem  to  occur  time  and  again. 

The  chief  drawback  to  the  system  is  the  consistency  of  the 
comments.  There  are  two  major  reasons  for  this;  the  personal 
expertise  of  the  many  different  reviewers  is  widely 
divergent,  and  what  expertise  there  is  tends  to  be 
specialized  within  the  design,  maintenance,  or  operations 
disciplines,  often  leading  to  some  aspects  of  a  review 
receiving  more  attention  than  others.  Another  cause  for  the 
lack  of  consistency  stems  from  the  absence  of  a  truly 
universal  method  for  performing  reviews.  In  addition,  there 
is  a  considerable  transiency  among  experts  in  the  field. 
When  they  leave  the  organization,  there  is  usually  not 
another  person  with  the  same  amount  of  expertise. 

All  of  these  reasons  are  classic  demonstrations  of  the  need 
for  the  development  of  a  KBES .  In  response,  USA  CERL , 
developed  the  BCO  (biddability,  constructability,  and 
operability)  Advisor.  It  is  an  evolutionary  step  forward 
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from  ARMS,  designed  to  interface  with  it  so  as  to  draw  on 
the  existing  capabilities,  while  providing  additional  input 
that  will  strengthen  it  even  further  by  improving  the 
generation  of  meaningful  comments. 

The  program  was  developed  using  KBES  technology,  and  is 
described  by  its  developers  as  an  expert  system,  although  it 
should  not  be  considered  to  be  a  full  blown  KBES  in  the 
sense  that  it  will  not  arrive  at  an  independent  family  of 
inferences,  given  a  set  of  initial  facts.  Nevertheless,  it 
is  still  a  useful  tool  that  interacts  with  the  reviewer  with 
easy  to  follow  menus.  The  review  results  in  a  list  of 
comments  that  are  sent  into  an  output  file  which  also 
contains  pertinent  data  such  as  the  reviewer's  name,  project 
name,  description,  location,  date  of  review,  etc. 

The  program  uses  a  multi-layered  approach,  with  the  reviewer 
being  prompted  with  menus  that  steer  him  through  the  review 
process.  At  the  uppermost  level,  the  reviewer  chooses 
between  biddability,  constructability,  or  operability 
reviews.  Then  he  is  given  a  choice  between  35%,  95%,  o-r 
Special  Issues  reviews. 

The  35%  review  presents  short  lists  of  comments  that  are 
typical  of  those  that  a  design  project  manager  could  expect 
to  make  to  a  design  A/E  firm.  These  lists  are  organized  into 
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various  categories  of  design  discipline  so  as  to  permit  the 
project  manager  to  maintain  a  consistent  train  of  thought 
during  the  review.  In  addition  to  the  traditional  design 
disciplines,  there  are  also  separate  categories  for 
environmental  and  operations  and  maintenance  issues.  The 
emphasis  at  the  35%  level  is  on  general  concepts  and  design 
production  issues  rather  than  on  qualitative  issues. 

The  95%  review  lists  comments  from  the  same  set  of  design 
disciplines,  but  further  divides  the  comments  into 
subcategories  corresponding  to  the  CSI  specification  format, 
i.e.,  general  c ondi t i ons , s i t ework ,  concrete,  etc.  In  all 
there  are  over  750  pre-written  comments  among  the  seven 
basic  disciplines. 

The  special  issues  review  option  provides  comments  for 
specialized  areas  of  interest  such  as  life  safety,  security, 
construction  scheduling,  etc.  There  is  also  a  category  for 
"Special  Facilities"  which  include  such  groups  as  waterfront 
operations,  fueling,  maintenance,  and  several  others.  Other 
categories,  presumably,  can  be  added  as  the  need  dictates. 

By  using  the  BCO  Advisor,  a  reviewer  without  much 
experience,  or  with  expertise  in  another  discipline,  is 
given  a  broad  range  of  heuristics  to  use  in  the  form  of 
predetermined  comments.  The  comments  are  presented  to  him  in 
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a  logical  sequence,  first  by  design  discipline , then  by  CSI 
specialty  within  the  discipline.  Other  considerations,  based 
upon  knowledge  about  environmental,  operational  and 
maintenance  issues  are  also  provided.  Thus  a  relatively 
inexperienced  reviewer  is  capable  of  performing  a  review 
with  considerable  scrutiny  and  the  results  are  in  a  format 
that  can  be  readily  assimilated  into  the  system  so  that 
those  needing  to  be  aware  of  his  findings  are  made  so  with 
little  t ime  lest. 

IMPROVING  THE  CONCEPT: 

As  written,  the  BCO  Advisor  lacks  depth,  even  though  the 
material  to  improve  it  is  already  embedded  in  the  system. 
What  the  reviewer  gets  now  is  the  same  set  of  lists  of 
comments  regardless  of  the  type  of  facility  being 
considered.  There  are  several  hundred  comments  that  may  not 
apply  to  every  type  of  facility.  BCO  Advisor  recognizes  that 
there  are  such  things  as  "special  facilities"  that  may  need 
additional  scrutiny,  and  includes  them  at  a  lower  level, 
among  several  other  categories  in  the  special  issues  review 
opt i on  . 

The  concept  that  some  facilities  are  somehow  "special" 
should  be  expanded  so  as  to  recognize  that  all  facilities 
are  unique  within  certain  specific  categories.  For  the 
Department  of  the  Navy,  establishment  of  category  codes, 
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nomenclature,  facility  type,  and  required  units  of  measure 
for  identifying,  classifying  and  quantifying  the  various 
facilities  is  done  by  the  NAVFAC  P-72,  Department  of  the 
Navy  Facility  Category  Codes.  There  are  nine  broad  DOD 
facility  classes,  which  are  subdivided  into  sixteen  category 
groups.  For  example,  the  broad  class  of  Operational  and 
Training  Facilities  is  further  subdivided  into  three 
category  groups,  Operational  (excluding  waterfront), 
Waterfront,  and  Training.  Within  each  of  these  category 
groups  the  individual  specific  facilities  are  assigned  basic 
category  numbers. 

To  illustrate,  the  following  examples  show  how  category 
codes  are  developed  for  a  "Public  Works  Shop",  and  a  "Water 
Distribution  Line,  Potable", 


Facility  Category  Basic 

C.  1  a  s  s _ flrnnp - Cad,  pg  nr  y 

200 

800 

210 

840 

219 

842 

219-10 

842-10 
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Nomenclature 


Maint  &  Prod  Facil 
Util  &  Grnds  Improv 
Maintenance  Group 
Water  Util  Group 
Facil  Maint  &  Repair 
Water  Distribution 
Public  Works  Shop 
Water  Dist  Line,  Pot 


A  KBES  to  perform  technical,  functional,  and 
constructability  reviews  should  be  able  to  access  the 
knowledge  base  that  it  possesses  in  such  a  way  as  to  infer 
which  advice  to  give  the  reviewer  based  upon  the  type  of 
review  that  is  being  performed  as  well  as  the  type  of 
facility  that  is  being  considered. 
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CHAPTER  FOUR 


THE  NEXT  GENERATION 

COMBINING  CADD,  CCB,  and  ConDoc : 

So  far,  the  work  that  has  been  done  in  the  burgeoning 
field  of  KBES  development  within  the  area  of  construction 
design  review  has  been  limited  to  the  infusion  of  new 
software  concepts  with  existing  hardware  in  an  attempt  to 
solve  the  problem  of  correcting  design  deficiencies  by 
improving  the  ability  of  reviewers  to  identify  and  provide 
high  quality,  consistent  comments  about  them. 

The  next  generation  should  embark  on  a  plan  to  attack  the 
problem  of  design  deficiencies  at  the  source,  the  drawing 
board.  The  use  of  Computer  Aided  Design  and  Drafting  (CADD) 
systems  is  now  prevalent  throughout  the  design  profession, 
and  becoming  more  so  as  further  development  brings  more 
system  configurations  to  the  market  at  more  affordable 
prices . 

CADD  permits  electronic  coordination  among  design 
disciplines.  Structural  systems  grids  can  be  overlaid 
electronically  with  architectural  plans  to  verify  spacial 
continuity.  Some  of  the  CADD  systems,  such  as  the  relatively 
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inexpensive  AUTOCAD  even  permit  study  of  all  three 
dimensional  planes  so  that  spacial  conflicts  can  be  seen 


that  would  not  appear  in  any  two  dimensional  review. 

Designers  rightfully  pride  themselves  on  their  ability  to  be 
innovative  thinkers,  yet  the  nature  of  drawing  production 
has  remained  virtually  unchanged,  even  with  the  widespread 
adoption  of  CADD  systems.  Computers  have  only  replaced  the 
drawing  boards,  not  the  methodology  used  to  lay  out  the 
drawings.  Contrast  this  with  the  enormously  complex 
production  of  construction  specifications.  The  Construction 
Specifications  Institute  (CSI)  sixteen  division 
specification  format  is  the  universally  accepted  standard 
within  the  Construction  Industry.  It  simplifies  and 
clarifies  the  enormous  amounts  of  information  that  must  be 
included  in  order  to  convey  the  intent  of  the  design  and  the 
standards  of  expectation  of  the  construction.  Communications 
is  thus  vastly  improved. 

With  the  CSI  approach  in  mind,  Guzey  and  Freehof  formulated 
the  system  called  ConDoc  in  1987  (Solomon,  1990) .  It 
standardizes  the  production  of  working  drawings  in  the  same 
way  CSI  did  the  specifications. 

ConDoc  begins  by  organizing  the  drawings  first  by  major 
discipline,  then  within  each  discipline  further  subdivisions 
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occur  that  serve  to  keep  similar  drawings  together.  A 
standardized  drawing  ident i f icat i on  system  can  thus  be 
created.  For  instance,  drawings  related  to  the  Architectural 
discipline  are  all  labeled  "A"  followed  by  a  number  that 
specifies  the  nature  of  the  drawing.  The  subdivisions  of 
Architectural  drawings  are  General  Information  (0) ,  Plans 
(1) ,  Exterior  Elevations  and  Transverse  Sections  (2) , 
Vertical  Circulation  (3),  Reflected  Ceiling  Plans  and 
Details  (4),  Exterior  Envelope  Details  (5),  and  Interiors 
(6) .  A  drawing  labeled  A203  is  the  third  sheet  of  the 
exterior  elevations  and  transverse  sections  group  within  the 
architectural  discipline. 

Additional  standardization  is  applied  to  the  sheet,  itself, 
dividing  it  into  zones  for  title  block  and  legend 
information  (zone  1) ,  graphics  (zone  2)  and  perimeter  margin 
(zone  3) .  Within  the  graphics  zone,  which  is  understandably 
the  largest  portion  of  the  sheet,  is  a  grid  composed  of 
modules  approximately  2"  by  1  3/4".  The  module  becomes  the 
basic  unit  for  sheet  organization.  Graphic  details  fit 
within  one  or  more  of  the  modules  to  form  a  module  block. 
The  module  block  can  take  up  the  entire  graphics  zone,  or 
only  part  of  it.  Each  module  block  has  its  own  organization 
that  parallels  that  used  for  the  entire  sheet,  i.e.  title 
block,  graphics  zone  and  perimeter  margin. 
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The  consistency  which  results  lends  itself  well  to  CADD 
application.  In  addition  ConDoc  can  link  drawings  with 
project  specifications  using  keynotes  that  relate  to  the  CSI 
specification  format.  The  computer  identifies  the  keywords 
appearing  on  a  sheet  and  prints  the  spec i f i cat i on  sections 
that  apply  in  the  legend  area  of  zone  1. 

The  power  of  this  system  can  be  even  further  enhanced  by 
combining  the  ConDoc  principle  with  the  Construction 
Criteria  Base  (CCB) .  The  CCB  was  created  in  the  1970' s  as  a 
PC  based  program  to  aid  in  the  production,  modification,  and 
distribution  of  Federal  Guide  Specifications.  In  its 
original  form,  it  was  contained  on  five  360  kilo-byte 
diskettes.  Todays  version  of  the  CCB  is  Commercially 
marketed  by  the  National  Institute  of  Building  Sciences 
(NIBS)  on  an  annual  subscription  basis  and  is  contained  on 
four  CD-ROM  compact  disks .  The  CCB  has  evolved  into  a  system 
for  electronic  dissemination  and  use  of  design  and 
construction  criteria  that  includes  guide  specifications, 
design  and  technical  manuals,  building  standards,  and 
similar  information.  The  system  of  electronic  data  bases 
contain  private  sector,  military,  and  other  federal  agency 
guide  specifications,  technical  manuals,  standards,  cost 
estimating  programs,  etc.  Included  are  the  complete  library 
of  vectorized  drawings  from  NAVFAC  P-272,  "Definitive 
Designs  for  Naval  Shore  Facilities". 
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The  CCB  puts  as  much  information  of  this  kind  at  the 
fingertips  of  the  members  of  the  building  community  as 
quickly  and  cost-effectively  as  possible.  Each  CD-ROM  disk 
effectively  reduces  the  burdensome  distribution  of  over 
250,000  pages  of  printed  information  or  1,600  floppy 
diskettes  of  information  that  it  contains. 

The  next  generation  involves  a  CADD  system  that  is 
integrated  with  a  KBES .  The  knowledge-base  of  the  KBES  has 
review  oriented  information  discussed  throughout  this  paper, 
and  also  design  oriented  information  such  as  ConDoc  and  the 
CCB.  A  design  project  manager  can  coordinate  the  design  and 
review  with  the  integrated  CADD  system. 

Design  A/E  firms  are  given  much  more  definitive  guidance  and 
have  the  wherewithal  to  study  the  cost  implications  of 
changing  materials  or  methods  of  construction.  The  designer 
will  also  have  the  best  cumulative  advice  available  from  the 
construction  managers,  as  well  as  operations  and  maintenance 
experts.  Reviewers  are  given  better  design  documents  to 
examine  during  all  phases  of  design  production.  There  is 
adequate  compensation  for  variations  in  individual  expertise 
at  every  level . 
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CHAPTER  FIVE 


CONCLUSIONS  AND  RECOMMENDATIONS 

The  problem  that  has  been  addressed  by  this  paper  is  the 
existence  of  design  deficiencies  that  remain  undetected  and 
cause  expensive,  post-award  contract  modifications.  Because 
the  owner  is  a  willing  participant  in  the  design  process,  he 
is  at  least  partially  culpable  if  he  does  not  properly 
review  the  design  documents.  Not  every  person  who  is 
assigned  the  task  of  reviewing  design  documents  has  the 
expertise  to  do  so. 

As  indicated  in  chapter  two,  the  task  of  performing 
technical,  functional  and  constructability  reviews  is 
suitable,  justifiable,  and  appropriate  for  development  into 
a  KBES  using  the  concepts,  hardware,  and  software  that  are 
available  today. 

Perhaps  even  more  exciting  is  a  vision  of  what  follows  next. 
With  the  adoption  of  ConDoc ,  and  the  existence  of  the 
Construction  Criteria  Base,  existing  CADD  systems  can  be 
integrated  with  a  knowledge-base  that  also  includes 
heuristic  knowledge  provided  by  expert  practitioners  from 
the  areas  of  construction  management,  operations,  and 
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maintenance , 


that  can 


dramat ically 
important  in 


into  a  powerful  design  tool 
increase  the  efficiency  that  will  be  even 
the  future. 


more 
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